\subsection{Datenintegrität}

\begin{itemize}
    \item Die Integrität der in Datenbanken abgelegten Daten wird durch eine Signierung der Daten durch das speichernde Modul gewährleistet (Maßnahme \ref{signonsave}). Da die Signaturen bei jedem Auslesen überprüft werden (Maßnahme \ref{verifyonload}), können sie nicht unbemerkt gefälscht werden, solange der Private Key der Module sicher verwahrt wird (Maßnahme \ref{safeprivkey}).

    \item Das Löschen von Transaktionen und Nachrichten ist datenbankseitig nicht möglich (Maßnahme \ref{nodeletetx} und \ref{nodeletemsg}).

    \item Alle Kommunikationskanäle sind durch TLS-Verschlüsselung abgesichert (Maßnahme \ref{tls}).

    \item Die Einschleusung von schadhaftem Code wird durch Überprüfung der Eingabeparameter mitigiert (Maßnahme \ref{sqlinj}).

    \item Insider-Attacken werden durch die Aufteilung der Verantwortung auf zwei Administratoren erschwert (Maßnahme \ref{sepadmin}). Insider-Attacken würden eine Verschwörung beider Administratoren erfordern.
\end{itemize}

\subsection{Authentizität}

\begin{itemize}
    \item Jeder Kunde und jeder Mitarbeiter muss sich erst beim \KM{} authentifizieren, bevor ihm Zugriff auf seine Informationen gewährt wird (Maßnahme \ref{authfirst}).

    \item Teile des Systems müssen sich gegenseitig authentifizieren, bevor ein gesicherter Kommunikationskanal geöffnet wird (Maßnahme \ref{tls}).

    \item Verwendete Public Keys werden immer bei der \CA{} auf Gültigkeit geprüft, bevor sie verwendet werden (Maßnahme \ref{ca}).

    \item Kreditkarten werden vor Beginn einer Transaktion auf Echtheit geprüft (Maßnahme \ref{checkcard}). Der dazu auf der Karte gespeicherte Private Key wird vor Fremdzugriff geschützt (Maßnahme \ref{safechip}).

    \item Kreditkartenbesitzer werden vor Beginn einer Transaktion auf Zugehörigkeit zur Karte geprüft (Maßnahme \ref{checkpin}).

    \item Benutzer-Accounts werden gesperrt, wenn das Passwort zu oft falsch eingegeben wird (Maßnahme \ref{lockifwrongpw}).

    \item Session-Hijacking oder MITM-Attacken werden durch die konsequente Verwendung von verschlüsselten Kommunikationskanälen mitigiert (Maßnahme \ref{tls}).

    \item Insider-Attacken werden durch die Aufteilung der Verantwortung auf zwei Administratoren erschwert (Maßnahme \ref{sepadmin}). Insider-Attacken würden eine Verschwörung beider Administratoren erfordern.
\end{itemize}

\subsection{Nichtabstreitbarkeit}

\begin{itemize}
    \item Zu einer Transaktion werden die Signaturen aller beteiligten Partner gespeichert und beweisen somit deren Teilnahme an der Transaktion (Maßnahme \ref{txsignatures}).

    \item Alle gespeicherten Datensätze werden bei der Eintragung bzw. nachfolgenden Änderungen von der \TSA{} signiert und garantieren somit, dass sie tatsächlich zu einem gewissen Zeitpunkt stattgefunden haben (Maßnahme \ref{tsa}). Diese Signatur wird von der allgemeinen Signatur des Datensatzes mitsigniert (Maßnahem \ref{signonsave}), die bei jedem Laden überprüft wird (Maßnahme \ref{verifyonload}), und somit fälschungssicher.

    \item Alte Datenzustände werden bei Änderungen mitversioniert, zusammen mit dem Benutzer, der die Änderung durchgeführt hat (Maßnahme \ref{versioning}). Dadurch kann überprüft werden, welcher Benutzer im Schadfall einen Eintrag manipuliert hat. Versionierte Tabellen werden signiert und dürfen durch Benutzer nicht geändert werden, wodurch sie vor Manipulationen geschützt werden (Maßnahme \ref{safeversioning}).
\end{itemize}

\subsection{Vertraulichkeit}

\begin{itemize}
    \item Alle Daten werden verschlüsselt gespeichert (Maßnahme \ref{encrpyt}).

    \item Daten werden verschlüsselt, bevor sie zur Signatur an die \TSA{} gesendet werden (Maßnahme \ref{encryptbeforetsa}).

    \item Der Datenbank-Adminsitrator hat zwar Zugriff auf die verschlüsselten Daten, nicht aber auf den Private Key, während der Security-Administrator Zugriff auf den Private Key, nicht aber auf die verschlüsselten Daten hat. Dadurch werden Insider-Attacken erschwert (Maßnahme \ref{sepadmin}).

    \item Private Keys werden sicher aufbewahrt (Maßnahme \ref{safeprivkey}).

    \item Sämtliche Kommunikationskanäle werden verschlüsselt (Maßnahme \ref{tls}), wodurch Session Hijacking und MITM-Attacken unschädlich gemacht werden.

    \item Passwörter werden zuerst gehasht, bevor sie verschlüsselt und in der Datenbank gespeichert werden. Dadurch ist selbst bei Zugriff auf die entschlüsselten Daten das Passwort vor Ausspähen geschützt (Maßnahme \ref{safepw}).
\end{itemize}

\subsection{Verfügbarkeit}

\begin{itemize}
    \item Module akzeptieren nur Verbindungen von bekannten IP-Adressen. Dadurch werden DDoS-Attacken erschwert (Maßnahme \ref{knownips}).
\end{itemize}

\subsection{Compliance}

\begin{itemize}
    \item Daten werden erst nach der gesetzlich vorgeschriebenen Aufbewahrungsfrist gelöscht (Maßnahme \ref{keepdata}).
\end{itemize}


